Fixes #7581

The first deliverable of the #5250 ruling (maintainer, 2026-09-04, batch #25, option 2 — a strict authoring face as a programme, measurement first). This PR ships nothing and repairs nothing: no schema in packages/types changes, no gate is wired, and .passthrough() on BaseSchemaCore is untouched. It adds one reproducible throwaway, scripts/measure-strict-authoring-face.mjs, plus the reading it produces.

The number, in one line

2100 nodes across the three corpora. 196 are refused by a strict twin; 137 of those are green today and red only under strict; the other 59 are already red under the face as shipped. 58 of the 94 component types seen are strict-clean — zero refusals. A naive .strict() flip over whole documents refuses 304 of 557 node documents, but that number measures the recursion point, not the components (see "the node boundary" below).

How to re-derive it

pnpm --filter @object-ui/types build
pnpm exec tsx scripts/measure-strict-authoring-face.mjs          # the report below
pnpm exec tsx scripts/measure-strict-authoring-face.mjs --json   # machine form

Output is deterministic — every list sorted, nothing timestamped — so two runs diff clean (verified, both formats). The report pins HEAD, the origin/main commit it forked from, and a mechanical answer to "does this tree's corpus still equal main's?", so the numbers can be re-derived after the declaration repairs of #6939 land and move them. #6939 was not merged in: this reading is fa7d66c45's.

The five decisions the measurement rests on

1. The registry is the arms of AnyComponentSchema (107 component types, zero collisions), not a type map built from all 206 module exports. That is not a style preference — it is measurably load-bearing: FilterFieldSchema declares type: z.enum(['text','select','number','date',…]) for a filter field, and an export-order registry hands it the text and select node types. The first draft of this script did exactly that and reported 718 text nodes with 704 strict refusals; the corrected registry reports 637 text nodes with 0.

2. Traversal is schema-guided, never "any object with a type key". A field definition { name: 'amount', type: 'currency' } and a node { type: 'text' } are structurally identical, and half the field-type vocabulary (text, number, date, select, html, label) collides with a node type. A value is a node only where the schema declares a SchemaNodeSchema slot; from there descent continues through that node's own schema. A type at a node slot resolving in no schema is counted, not dropped.

3. The node boundary. Child slots are z.union([SchemaNodeSchema, z.array(SchemaNodeSchema)]), and SchemaNodeSchema resolves to BaseSchemaCore — the ~21 base keys and nothing type-specific. Strict-ifying that recursion point makes every child node's own declared props unrecognised, so it measures the recursion point rather than the components. The per-component tables therefore replace SchemaNodeSchema with z.any() and flatten each document into nodes judged against their own schemas. Both readings are reported; the whole-tree one (304/557) is what a naive flip would really do, and it is the programme's first structural finding: the recursion point must be redirected to AnyComponentSchema before strict can be switched on at all.

4. Three twins per schema. baseline (the face as shipped, boundary applied) tells you what is red today; strict adds catchall: never everywhere; keyProbe is a shape skeleton — same keys, every leaf z.any(), every member optional, union arms merged key-wise — that cannot fail, so diff(input, keyProbe.parse(input)) enumerates undeclared keys exactly, including on nodes that are red for value reasons and would otherwise yield no parse output to diff. Objects are cloned by patching _zod.def and calling their own constructor rather than rebuilt with z.object(shape), because the latter drops .refine() checks and a twin that quietly lost a refinement would under-report red.

5. The predicates, stated because the card asks for them. Node document: parses, is a plain object, carries a string type, and that type resolves in the registry. Fragment (docs only): a ```json fence whose body does not parse as JSON — the deliberate-snippet shape; counted, never silently skipped, and this count is the price tag on finding: no gate reads a doc snippet's schema KEYS against the spec — #4823's deferred "second dimension", closed unbuilt #5138. Non-document: parses but fails one of the other three, split into notAnObject / noTypeKey / unresolvedType — the last kept apart because such a document is refused by AnyComponentSchema today.

Corpus enumeration — mine beside the PM's

⚠️ The apps half of corpus 3 is nearly empty, and that is the finding. Because apps/**/*.json holds no authored documents, corpus 3 was widened mechanically to .ts modules under apps/** and packages/*/examples/** that carry a type: '…' literal in source; those are imported and their exported plain objects harvested. That yields 19 items and only 2 node documents. The apps' real authored surface is JSX inside *-preview.tsx harnesses and metadata-designer drafts in preview-samples.ts that are spec records (objects, tools, jobs), not node documents. One module could not be imported and is recorded rather than skipped.

Cross-reference against the cards named on #7581

• 24 catalog entries fail safeValidateSchema because the Zod mirror names a key its renderer never reads (8 components) #6939 (open, in flight) — "24 catalog entries fail safeValidateSchema". Its 8 components (tooltip, context-menu, tree-view, kanban, filter-builder, chart, +2) are a subset of what the already-red-today column here reports: 20 whole catalog documents red today at the root, 23 catalog nodes red today, and a wider component set (resizable, carousel, flex, page, badge, select, list-view, object-grid, object-form, data-table, detail, grid, icon, list, alert, collapsible, button, form, dashboard) once nested nodes are judged too. ⛔ Nothing here was repaired.
• ChartSchema declares neither chart-level data nor xAxisKey — yet its own JSDoc teaches both, so the corrected chart model documents keys only BaseSchema's index signature admits #7549 (closed) — ChartSchema declares neither chart-level data nor xAxisKey. The same class shows up on a different owner here: dashboard → widgets.[].options.data×11, widgets.[].options.xField×11, widgets.[].options.yField×11. Different keys, different schema; listed so triage can tell them apart.
• finding(components): button-group implements no selection, and never wires the per-button onClick / disabled it declares — the catalog authors 29 keys nothing reads #7077 (closed) — the "key nothing reads" retirement shape. The renderer-mention probe below is the mechanical first cut at that split; its zero-mention rows (columnSpan, fullWidth, itemTemplate, rowSpan, summary_field, summary_object, totalItems) are the finding(components): button-group implements no selection, and never wires the per-button onClick / disabled it declares — the catalog authors 29 keys nothing reads #7077-shaped candidates.
• finding(examples): a catalog menu item authors variant: "destructive", a key no arm of MenuItem declares and no menu renderer reads — but the repair has a real fork #7101 (closed) — variant: "destructive" on a catalog menu item. variant still appears here as an undeclared key ×8 (badge×2 among others), so the class is not exhausted; ⛔ not repaired.
• finding: no gate reads a doc snippet's schema KEYS against the spec — #4823's deferred "second dimension", closed unbuilt #5138 — the fragment-marking question. Its price tag: 25 fragments and 20 fences that parse but carry no type key, out of 204.

Findings filed separately (⛔ not repaired here)

Two things the measurement surfaced that are not undeclared-key results, deduped against the open backlog before filing:

• BreadcrumbSchema and ObjectTreeSchema are not exported by name from @object-ui/types/zod — reachable only through the union, so no consumer can validate one alone.
• Ten z.lazy exports rebuild their schema on every getter call (getter() === getter() is false), so the schema is reconstructed per parse and cannot be compared by identity.

Everything else is listed below rather than filed, which #7581 explicitly permits ("file it … or list it in the report").

Gates

The corpus pin has a verified negative leg: appending a line to one content/docs file flips corpus identical to that main commit to NO, and git checkout HEAD -- content/docs restores the file byte-identically (blob 6aa5e59 → 1d59f6a → 6aa5e59, git diff HEAD -- content/docs empty).

Strict authoring face — measurement (objectui#7581)

• HEAD 0044a60218eba4993b0a6e64e8697068c98756c4 · forked from origin/main at fa7d66c4505d0fcc866fbecec1901c4990a80c3a
• corpus identical to that main commit: yes (compared over examples/schema-catalog/src/schemas, content/docs, apps, packages/types/src)
• zod 4.4.3 · face read from packages/types/dist/zod/index.zod.js
• node schemas in the registry (arms of AnyComponentSchema): 107 component types

Per corpus

Headline

Top undeclared keys — top level (what BaseSchemaCore.passthrough() admits today)

Top undeclared keys — nested inside declared members

Undeclared keys × does any renderer source mention the identifier?

Coarse triage hint only — see the rendererMentions docblock. A key with 0
mentions is #7077-shaped (nothing reads it); a key with mentions is #6939-shaped
(the renderer reads it, the schema does not declare it). Both still need the call
site read before they become worklist items.

Probe controls — className (must be > 0): 13409; zzzFabricatedControlKey (must be 0): 0 ⇒ probe is live.

Why the nodes that are ALREADY red today are red (top issues)

These are refused by the face as shipped; strict is not what broke them.

Per component type

type values that resolve in no node schema (refused by AnyComponentSchema today)

At a document root:

At a declared child-node slot:

Registered component types with zero documents in any corpus

calendar, chatbot-enhanced, chatbot-floating, crud-dialog, object-calendar, object-chart, object-data-table, object-gallery, object-tree, report, report-builder, report-viewer, span

Node schemas not exported by name from @object-ui/types/zod

breadcrumb, object-tree — reachable only through the union, so no consumer can validate one of these alone.

z.lazy exports whose getter rebuilds the schema on every call

ActionSchema, AppMenuItemSchema, FilterBuilderConditionSchema, FilterGroupSchema, MenuItemSchema, NavLinkSchema, NavigationItemSchema, NavigationMenuItemSchema, SchemaNodeSchema, TreeNodeSchema — getter() === getter() is false, so the schema is reconstructed on every parse and no consumer can compare it by identity.

The TypeScript face — where [key: string]: any is declared

packages/types/src declares the index signature at 12 sites, and 120 interfaces extends BaseSchema directly (so they inherit it).

Walker limits — shapes strict could not close

• opaque custom node — strict cannot reach inside it: (inline custom)
• opaque function node — strict cannot reach inside it: (inline function)
• opaque transform node — strict cannot reach inside it: (inline transform)

Authored-module loading (corpus 3)

• ⚠ apps/console/src/pages/developer/hooks/useApiDiscovery.ts: Cannot find module '/home/user/objectui-issue-7581/apps/console/node_modules/@object-ui/app-shell/dist/index.js' imported from /home/user/objectui-issue-7581/apps/console/src/pages/developer/hooks/useApiDiscovery.ts

Modules that PRINT when imported (console muted for the run): packages/types/examples/zod-validation-example.ts

🤖 Generated with Claude Code

https://claude.ai/code/session_013uAaxiwgYDybsTNV9xwa1M

Generated by Claude Code